1.1 Field of the Invention
The present invention relates to transaction processing technology. More particularly the current invention relates to means and a method for executing a nested transaction in an execution environment supporting execution of flat transactions only.
1.2 Description and Disadvantages of Prior Art
Transaction processing technology is exploited to administrate, manage and coordinate the flow of the multitude of concurrently processing transactions through the computer system. It orchestrates the commit and undo, i.e. rollback, of transactions as well as the recovery of objects, resource managers, or sites after they fail.
The above mentioned consistency requirement for a certain transaction and for all other concurrently processing transactions in the local or distributed transaction system is more accurately expressed as the ACID requirement. Actually ACIDicity is a combination of four different sub-requirements:                atomicity A transaction's changes to the state of the overall system are atomic; either all happen or none happen. This so-called all-or-nothing property ensures that either the transaction completes successfully or aborts and has no effect on data or resources in general. These changes include all changes to resources including database changes, messages, actions on transducers and so forth.        consistency A transaction is a correct transformation of the system state. The actions taken as a group do not violate any of the integrity constraints associated with the state. This requires that the transaction be a correct program. As the result data are in a consistent state before the transaction starts and they are again in a consistent state after the transaction has finished.        isolation Even though transactions execute concurrently, it appears to each transaction T, that other transactions execute either before T or after T, but not both. Therefore intermediate states and intermediate changes to resources of one transaction are not visible to the other transactions. This principle is also commonly referred to as serializability.        durability Once a transaction completes successfully and it commits its activities, its changes to the state survive failures, i.e. the state changes (changes to resources) became permanent after the transaction has completed successfully. In terms of object oriented programming for instance this is referred to as persistence.        
Various types of transaction models do exist.
The simplest form of a transaction model is the flat transaction which comprises all operations within a StartTransaction and EndTransaction statement; the EndTransaction statement may be represented by a CommitTransaction or RollbackTransaction statement.
A more sophisticated transaction model is the nested transaction wherein within an outermost transaction a multitude of further transactions nested to any arbitrary depth are encapsulated.
These concepts are described in further details for instance by J. Gray “Transaction Processing: Concepts and Techniques”, 1992. Morgan Kaufmann Publishers. ISBN: 1558601902.
One problem created by this coexistence of different transaction models is that programs written for and performing a nested transaction cannot be executed within an execution environment supporting a flat transaction model only. A further problem area relates to the area of program development. In terms of intelligibility and maintainability programs are to be designed as modular as possible without context dependencies between different modules to be paid attention to by a programmer. The smaller the context to which a programmer has to pay attention, the less programming errors will occur. The most well-known programming paradigm realizing this principle is the object oriented programming concept. Real world functions, which have to be executed as a single transaction, do require that many objects would have to be manipulated within a single transaction. Exploiting the nested transaction model, complex context situations can be avoided for instance by enclosing individual modifications of an object as encapsulated transactions. But in case the execution environment, for instance the underlying database storing the object data, does not support a nested transaction model this even would have an undesired influence on the programming style; larger programming contexts will have to be established to guarantee the transactional execution of more complex operations. A well-known example of execution environments which support flat transaction models only are access interfaces to relational database systems.
1.3 Objective of the Invention
The invention is based on the objective to provide an approach for executing a nested transaction in an execution environment supporting a flat transaction only.